Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AST/Sema/SILGen: Implement tuple conversions #23591

Merged
merged 3 commits into from
Mar 28, 2019

Conversation

slavapestov
Copy link
Contributor

@slavapestov slavapestov commented Mar 27, 2019

This PR picks up where #23458 left off.

TupleShuffleExpr could not express the full range of tuple conversions that
were accepted by the constraint solver; in particular, while it could re-order
elements or introduce and eliminate labels, it could not convert the tuple
element types to their supertypes.

This was the source of the annoying "cannot express tuple conversion"
diagnostic.

Replace TupleShuffleExpr with DestructureTupleExpr, which evaluates a
source expression of tuple type and binds its elements to OpaqueValueExprs.

The DestructureTupleExpr's result expression can then produce an arbitrary
value written in terms of these OpaqueValueExprs, as long as each
OpaqueValueExpr is used exactly once.

This is sufficient to express conversions such as (Int, Float) => (Int?, Any),
as well as the various cases that were already supported, such as
(x: Int, y: Float) => (y: Float, x: Int).

https://bugs.swift.org/browse/SR-2672, rdar://problem/12340004

@slavapestov
Copy link
Contributor Author

I still need to add some tests, but I'm going to check source compat first.

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

OpaqueValueState used to store a SILValue, so back then the IsConsumable flag
was meaningful. But now we can just check if the ManagedValue has a cleanup
or not.

Also, we were passing around an opened ArchetypeType for no good reason.
TupleShuffleExpr could not express the full range of tuple conversions that
were accepted by the constraint solver; in particular, while it could re-order
elements or introduce and eliminate labels, it could not convert the tuple
element types to their supertypes.

This was the source of the annoying "cannot express tuple conversion"
diagnostic.

Replace TupleShuffleExpr with DestructureTupleExpr, which evaluates a
source expression of tuple type and binds its elements to OpaqueValueExprs.

The DestructureTupleExpr's result expression can then produce an arbitrary
value written in terms of these OpaqueValueExprs, as long as each
OpaqueValueExpr is used exactly once.

This is sufficient to express conversions such as (Int, Float) => (Int?, Any),
as well as the various cases that were already supported, such as
(x: Int, y: Float) => (y: Float, x: Int).

https://bugs.swift.org/browse/SR-2672, rdar://problem/12340004
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov
Copy link
Contributor Author

The source compat failure is an unexpected pass from a swiftpm change:

23:53:19   UPASS: https://bugs.swift.org/browse/SR-8234, Lark, 4.0, 7604f9, Swift Package

@slavapestov slavapestov merged commit 181e5d5 into swiftlang:master Mar 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant